Communications device and method comprising user profiles matching between compatible devices

ABSTRACT

A communications device comprising a memory adapted to store at least one profile of a user of the device, wherein the said at least one profile contains predetermined attributes and requirements of the user, a communicator adapted to exchange information with a compatible device; a controller adapted to register a match between information sent by the said device and information received from a compatible device, only when said requirements match attributes of the said compatible device and the said attributes match requirements of the said compatible device; and a user alert adapted to alert a user when the controller has established that a match has been made; wherein the said communicator is adapted to receive information relating to the requirements from the said compatible device, and not said information relating to the said attributes.

This invention relates to a communications device and method for sendinginformation between compatible such communications devices.

Many people experience problems meeting new people who share commoninterests. Typically this is due to shyness or lack of confidence. Oftenit is because of an inability to locate or identify suitableindividuals. For example, a person who lives in a big city and who islooking for a relationship based on casual sex may walk past manysuitable potential partners, all similarly desiring casual sex on adaily basis. However, it is extremely unlikely that such a person wouldidentify the potential partners that come into proximity at all, letalone interact with them. It is not easy for such a person to advertisetheir desires by means of a physical marker, since this can create asocial stigma and could actually be off-putting to potential partners.

It is similarly the case that a person could be interested in finding anew tennis partner. Again, the person might well routinely pass manysuitable partners, unaware of their suitability. Although discretion isless important when trying to find a partner to meet a need such asthis, the person would still find it difficult to make his or her desirefor a tennis partner known to suitable people.

Although recent advances in the Internet have provided a wealth ofopportunities for people to share information, these all suffer fromserious inherent difficulties when serving as a means for users to meetnew people, particularly where this is for romantic needs. For example,Internet chat rooms provide a forum in which people can converse freely,unhindered by the usual inhibitions of normal face-to-face contact. Thiscan alleviate the problems associated with the natural coyness of someusers, when it comes to discussing romantic issues with strangers, forexample. However, a consequence of the lack of face-to-face interactionis that a user has little or no way of verifying the informationcommunicated to them by other users. Also, for a user to arrange ameeting with another user, both users will almost inevitably have todivulge personal information, which could include physicalcharacteristics and contact details. This need to divulge personalinformation has serious security drawbacks, as revealing even modestpersonal details over the Internet can lead to dangerous and unwantedattention.

Similarly, there has been huge recent growth in personal mobilecommunications technology, especially with the escalation in popularityof mobile telephones. However, these devices are also largely unsuitablefor meeting new people with shared interests, and are more suited tofacilitating communication between users already acquainted with eachother.

There therefore remains a need for a means to enable users to find, andif desired, meet others who share the same interests as them, withoutdivulging their personal details to the world at large.

There is also a need for businesses to find new avenues to alertpotential consumers of their products or services. Potential customersare continually bombarded with advertisements, often with little or notargeting.

To overcome some of the foregoing problems, WO 97/49192 discloses aportable electronic device for facilitating communications between userspossessing compatible devices. The device incorporates a keypad and usesradio signals to communicate with other such devices. A user selectstheir requirements via the keypad, and communication is established withthose devices whose users have made the same key selection. The keys ofthe device are set to pre-determined functions, which can be changed bythe use of plug-in cards and interchangeable masks on the keypad.

Conventional communications devices such as those described in WO97/49192 provide means for facilitating the meeting of users with sharedinterests (i.e. those who have selected the same key pattern). However,systems of this type rely on each user being aware of the meaningcorresponding to each key selection. Furthermore, although the keypadsmay be changeable, such devices are not configurable to the preciseneeds of the user, as they are inherently reliant on a predetermined andfinite list of options.

Other conventional communications devices for matching the interests ofusers, such as those described in WO 00/22860, rely on the use of acentral database to store information relating to the needs of the user.In such systems, each user carries a mobile electronic device thatrelays positional data of the user through a wireless connection to abase station, and on to a central database, which registers informationrelating to the position of each user. The user is then automaticallynotified of the proximity of other users whose interests match theirs.

When two users are proximate each other, the central database is checkedto see if their stored profiles match and if a match is detected, theusers are alerted. Such systems have the drawback that they areinherently reliant on a large infrastructure comprising a network ofbase stations and a central database. They are also reliant on thewireless technology used by the portable devices being capable ofrelaying the user's positional data.

It is an object of the present invention to provide a communicationsdevice and associated communications method that obviates many of theproblems associated with conventional devices for matching the interestsof users with compatible devices.

According to a first aspect of the invention there is provided acommunications device comprising: a memory adapted to store at least oneprofile of a user of the device, wherein the said at least one profilecontains predetermined attributes and requirements of the user; atransceiver adapted to transmit information relating to the saidrequirements to a compatible device and receive information relating torequirements of the said compatible device; a controller adapted toregister a match between the said device and the said compatible device,only when the said attributes match the said requirements of the saidcompatible device; and a user alert adapted to alert a user when thecontroller has established that a match has been made; wherein the saiddevice does not need to receive information relating to attributes ofthe said compatible device, in order to register a match with the saidcompatible device.

Such a device is thus adapted to ensure that the user of both the deviceand the compatible device match each other before either user isalerted. The device is adapted to register a match relying only on theexchange of requirements of the users, and not the attributes. Noartificial intelligence is required to match the users, as matches aredetermined by comparing received requirements with stored attributes.This contrasts to conventional systems, which generally attempt to matchusers based on what each user has told the system about him or herself.

In a particularly preferred embodiment the user alert is adapted toalert the user only when the controller has established that a match hasbeen made and that a match signal has been received from the compatibledevice, said match signal indicating that the compatible device hasregistered a corresponding match.

Preferably the device may comprise a display. The display may be adaptedto display an indication of the or each profile stored in the device.

In a preferred embodiment the device is adapted to allow the user todesignate which of the stored at least one profiles the user designatesas active; the said memory is further adapted to store an indication ofthe active profile or profiles; and the communicator is further adaptedto exchange information with a compatible device based only on theactive profile or profiles. The device may comprise a keypad, saidkeypad being adapted to allow a user to activate a profile from thosestored in the device. In a preferred embodiment the display is furtheradapted to display an indication of the active profiles. The memory maycomprise a combination of volatile and non-volatile memory.

The user alert may be adapted to provide a visual indication to theuser. In a preferred embodiment the user alert is adapted to provide thevisual indication using the display. The user alert may comprise atleast one LED. The user alert may be adapted to provide an audibleindication to the user. The user alert may be adapted to provide avibrating indication to the user.

In a preferred embodiment the or each said profile comprises aself-describing data file, each self-describing data file comprising atleast one field. The or each said profile may comprise at least one of aplurality of possible field types. The or each said profile can compriseone or more sets of fields of a keyword type, said one or more sets offields allowing matching to be performed against user determined freetext. The or each said profile may comprise a field that can contain amandatory flag, the said mandatory flag indicating to the device whetherblank fields are required to always or never be matched against. In apreferred embodiment, the memory is adapted to store multiple instancesof the same profile type; wherein the device is adapted to: match allthe multiple instances of the same profile in a matching process thatinvolves transmitting a two dimensional matrix of flags that indicate amatch or no match, the columns of said matrix being indexed on theinstances of the profile stored in the memory; receive a correspondingtwo dimensional matrix from the compatible device; transform thereceived matrix; and compare the transformed received matrix with thesent matrix to identify any and all matches for this profile type.

The or each said profile may comprise a header section, the headersection comprising a unique profile ID of the respective profile. In apreferred embodiment the header section is the only section of the oreach said profile that cannot be modified by the user.

In a particularly preferred embodiment the attributes and requirementsof the or each said profile are determined by the user.

Preferably the device is adapted to communicate with a suitablyprogrammed computer. The device may be adapted to communicate with thesuitably programmed computer using a cable connection between the deviceand the suitably programmed computer. The device may be adapted tocommunicate with the suitably programmed computer using the saidtransceiver. In a preferred embodiment the device is adapted to storethe populated at least one profile, upon receipt of information relatingto the said attributes and requirements from the said computer. Thedevice may be adapted to store new profile types, upon receipt ofinformation relating to the said new profile types from the saidsuitably programmed computer. The said information relating to the saidnew profile types may be downloaded to the said suitably programmedcomputer from any of the Internet, an email attachment, or a MMSattachment.

The device may comprise a timer and a timing register, and wherein thetiming register is adapted to store timing information for the or eachsaid profile. Preferably the timing information comprises apredetermined active period for the or each said profile. The timinginformation may comprise a schedule relating to the activation anddeactivation of the or each said profile at user defined times.

In a particularly preferred embodiment the memory is adapted to store aunique ID of the device. The memory may comprise a recent encounterscache, the said recent encounters cache comprising a list of receivedunique IDs of compatible devices that have communicated with the device.The device may be further adapted to allow the user to blacklistcompatible devices after the establishment of a match, and wherein thememory comprises a blacklist cache, the said blacklist cache comprisinga list of received unique IDs of compatible devices that the user hasblacklisted.

In a preferred embodiment the device comprises a probe alert, the saidprobe alert being adapted to aid the user physically to locate the userof the compatible device once a match has been established. The probealert may be adapted to provide a visual location indication to theuser. The probe alert may comprise at least one LED. The probe alert maybe adapted to provide the visual location indication to the user usingthe display. The probe alert may adapted to provide an audible locationindication. The probe alert may be adapted to provide a vibratinglocation indication.

In a preferred embodiment the device is adapted to store at least onehandle, the or each said handle generally comprising a string ofcharacters, and wherein the device is adapted to enable the or each saidhandle to be sent to the compatible device on the establishment of amatch. The or each said handle may comprise information pertaining tothe established match. The memory may be adapted to store a match log,the said match log comprising information regarding previouslyestablished matches. In a particularly preferred embodiment the matchlog may comprise a unique ID of each previously matched compatibledevice along with any received handles. The match log may compriseinformation regarding details of communications between the device andcompatible devices that did not result in a match. The device may beadapted to upload the contents of the match log to the suitablyprogrammed computer.

In a preferred embodiment the memory is adapted to store only profilesthat comprise a predetermined flag in the header section. Preferably thepredetermined flag is formed from a number of bits of the Profile ID,and the device adapted only to match with compatible devices that haveat least one stored profile with an identical corresponding bit set ofthe predetermined flag.

In a particularly preferred embodiment the transceiver is adapted toexchange information with the compatible device using short rangewireless communications. The short range wireless communications mayemploy radio or microwave transmission. The wireless communication mayemploy Bluetooth or Wi-Fi transmission. The wireless communication mayemploy any location aware telecommunications network. The location awaretelecommunications network may employ 3G transmission.

The transceiver may be adapted to exchange information with thecompatible device using long range wireless communications.

The device may be a portable device. The portable device may be any oneof, or a combination of: a mobile telephone, a PDA, a pager, a palmtopcomputer, a notebook computer or a laptop computer. The device may beadapted to perform any one of, or a combination of: populating the or,each said profile, creating new profiles, connecting to the Internet oraccessing email or MMS attachments and downloading new profiles.

The device may not be portable. The device may be any of: a personalcomputer, workstation, server, or terminal. The device may be adapted toperform any one of, or a combination of: populating the or each saidprofile, creating new profiles, connecting to the Internet or accessingemail or MMS attachments and downloading new profiles.

In a preferred embodiment the memory is adapted to store at least oneprofile that is a symmetric profile, the said symmetric profilecomprising a set of attributes and requirements fields which is adaptedto be symmetric with respect to that of a compatible device.

In a preferred embodiment the memory is adapted to store at least oneprofile that is an asymmetric profile, the said asymmetric profilecomprising a set of attributes and requirements fields that is adaptedto be asymmetric with respect to that of a compatible device. The devicemay be adapted to store an indication of whether the user is a provideror a finder in the profile. The said asymmetric profile may comprisemultiple instances of the attributes of the user. The device may beadapted to populate the attributes of the said asymmetric profile byreferencing an external database, the said external database beingstored on any of a LAN, a WAN, personal computer, workstation, server,terminal or the Internet. The device may be adapted to store the resultsof the reference to the external database after a match has beenestablished, if the user of the compatible device becomes out of rangebefore the user of the device is alerted to the match; and alert theuser to the match if the user of the compatible device becomes in rangeagain within a predetermined time period, without referring to theexternal database again.

In an embodiment the device is adapted to upload the or each saidprofile to a central database, said central database being adapted tostore location information relating to the users; and match users basedon the attributes and requirements of the or each said profile and thelocation information relating to the users.

According to a second aspect of the invention there is provided acommunications method comprising the steps of: storing at least oneprofile of a user in a memory of a communications device, wherein the oreach said profile contains predetermined attributes and requirements ofthe user; using a transceiver of the device to transmit informationrelating to the said requirements to a compatible device and receiveinformation relating to requirements of the said compatible device;using a controller to register a match between the said device and thesaid compatible device, only when the said attributes match the saidrequirements of the said compatible device; and using a user alert toalert a user when the controller has established that a match has beenmade; wherein the said device does not need to receive informationrelating to attributes of the said compatible device, in order toregister a match with the said compatible device.

In a particularly preferred embodiment the user is alerted only when amatch has been registered and a match signal has been received from thecompatible device, the said match signal indicating that the compatibledevice has registered a corresponding match.

Preferably the method further comprises the step of using a display todisplay an indication of the profiles stored in the device.

In a preferred embodiment the method further comprises the steps ofallowing the user to designate which of the stored at least one profilesare designated as active; storing an indication of the active profile orprofiles in the memory; and exchanging information with a compatibledevice based only on the active profile or profiles. The method maycomprise the step of using a keypad to activate a profile from thosestored in the device. The method may comprise the step of using thedisplay to display an indication of the active profile or profiles. Thememory may comprise a combination of volatile and non-volatile memory.

The method may comprise the step of using the user alert to provide avisual indication to the user. In a preferred embodiment the visualindication may be provided using the display. The visual indication maybe provided using at least one LED. The method may comprise the step ofusing the user alert to provide an audible indication to the user. Themethod may comprise the step of using the user alert to provide avibrating indication to the user.

In a preferred embodiment the or each said profile comprises aself-describing data file, each self-describing data file comprising atleast one field. The or each said profile may comprise at least one of aplurality of possible field types. The or each said profile may compriseone or more sets of fields of a keyword type, said one or more sets offields allowing matching to be performed against user determined freetext. The or each said profile may comprise a field that can contain amandatory flag, the said mandatory flag indicating to the device whetherblank fields are required to always or never be matched against. In apreferred embodiment, the method may further comprise the steps ofstoring multiple instances of the same profile type in the memory;matching all the multiple instances of the same profile in a matchingprocess that involves transmitting a two dimensional matrix of flagsthat indicate a match or no match, the columns of said matrix beingindexed on the instances of the profile stored in the memory; receivinga corresponding two dimensional matrix from the compatible device;transforming the received matrix; and comparing the transformed receivedmatrix with the sent matrix to identify any and all matches for thisprofile type.

The or each said profile may comprise a header section, the headersection comprising a unique profile ID of the respective profile. In apreferred embodiment the header section is the only section of the oreach said profile that cannot be modified by the user.

In a particularly preferred embodiment the user determines theattributes and requirements of the at least one profile.

Preferably the device communicates with a suitably programmed computer.The device may communicate with the suitably programmed computer using acable connection between the device and the suitably programmedcomputer. The device may communicate with the suitably programmedcomputer using the said transceiver. In a preferred embodiment thedevice stores the populated profile, upon receipt of informationrelating to the said attributes and requirements from the said computer.The device may store new profile types, upon receipt of informationrelating to said new profile types from said suitably programmedcomputer. The said information relating to the said new profile typesmay be downloaded to said suitably programmed computer from theInternet, or via an email attachment or MMS attachment.

The method may comprise the step of storing timing information for theor each said profile in a timing register. Preferably the timinginformation comprises a predetermined active period for the or each saidprofile. The timing information may comprise a schedule relating to theactivation and deactivation of the or each said profile at user definedtimes.

In a particularly preferred embodiment the device stores a unique ID ofthe device. The memory may comprise a recent encounters cache, the saidrecent encounters cache comprising a list of received unique IDs ofcompatible devices that have communicated with the device. In apreferred embodiment the user can optionally blacklist compatibledevices after the establishment of a match, and wherein the memorycomprises a blacklist cache, the said blacklist cache comprising a listof received unique IDs of compatible devices that the user hasblacklisted.

In a preferred embodiment the method comprises the step of using a probealert to aid the user to physically locate the user of the compatibledevice once a match has been established. The said probe alert mayprovide a visual location indication to the user. The probe alert maycomprise at least one LED. The probe alert may use the display toprovide the visual location to the user. The probe alert may provide anaudible location indication to the user. The probe alert may provide avibrating location indication.

In a preferred embodiment at least one handle is stored in the device,the or each said handle generally comprising a string of characters, andwherein the device sends the or each said handle to the compatibledevice on the establishment of a match. The or each said handle maycomprise information pertaining to the established match. A match logmay be stored in the memory, the said match log comprising informationregarding previously established matches. The match log may comprise aunique ID of each previously matched compatible device along with anyreceived handles. The match log may comprise information regardingdetails of communications between the device and compatible devices thatdid not result in a match. The device may upload the contents of thematch log to the suitably programmed computer.

In a preferred embodiment only profiles that comprise a predeterminedflag in the header section are stored in the memory. Preferably, thepredetermined flag may be formed from a number of bits of the ProfileID, and wherein the device only attempts to match with compatibledevices that have at least one stored profile with an identicalcorresponding bit set of the predetermined flag.

In a particularly preferred embodiment the transceiver exchangesinformation with the compatible device using short range wirelesscommunications. The short range wireless communications may employ radioor microwave transmission. The wireless communications may employBluetooth or Wi-Fi transmission. The wireless communication may employany location aware telecommunications network. The location awaretelecommunications network may employ 3G transmission.

The transceiver may exchange information with the compatible deviceusing long range wireless communications.

The device may be a portable device. The portable device may be any oneof or a combination of: a mobile telephone, a PDA, a pager, a palmtopcomputer, a notebook computer or a laptop computer. The method maycomprise the steps of using the portable integrated device to performany one of, or a combination of: populating the or each said profile,creating new profiles, connecting to the Internet or accessing email orMMS attachments and downloading new profiles.

The device may not be portable. The device may be any of: a personalcomputer, workstation, server, or terminal. The device may perform anyone of, or a combination of: populating the or each said profile,creating new profiles, connecting to the Internet or accessing email orMMS attachments and downloading new profiles.

In a preferred embodiment the method comprises the steps of using atleast one profile that is a symmetric profile stored in the memory, thesaid symmetric profile comprising a set of attributes and requirementsfields which is adapted to be symmetric with respect to that of acompatible device.

In a preferred embodiment the method comprises the steps of using atleast one profile that is an asymmetric profile stored in the memory,the said asymmetric profile comprising a set of attributes andrequirements fields that is adapted to be asymmetric with respect tothat of a compatible device. The device may be adapted to store anindication of whether the user is a provider or a finder in the profile.In a particularly preferred embodiment the said asymmetric profilecomprises multiple instances of the attributes of the user. The devicemay populate the attributes of the said asymmetric profile byreferencing an external database, the said external database beingstored on any of a LAN, a WAN, personal computer, workstation, server,terminal or the Internet.

The method may further comprise the steps of: storing the results of thereference to the external database after a match has been established,if the user of the compatible device becomes out of range before theuser of the device is alerted to the match; and alerting the user to thematch if the user of the compatible device becomes in range again withina predetermined time period, without referring to the external databaseagain.

In an embodiment, the method may further comprise the steps of:uploading the or each said profile to a central database, said centraldatabase being adapted to store location information relating to theusers; and matching users based on the attributes and requirements ofthe or each said profile and the location information relating to theusers.

According to a third aspect of the invention there is provided acommunications system comprising at least two communication devicesusing symmetric profiles, wherein the controller of each device isrespectively adapted to register a match between the device and theother device based on the symmetric profile, wherein the system isadapted to treat the attributes and requirements of each respective userequally.

According to a fourth aspect of the invention there is provided acommunications system comprising at least two communication devicesusing asymmetric profiles, wherein the controller of each device isrespectively adapted to register a match between the device and theother device based on the asymmetric profile, wherein the system isadapted to treat the attributes and requirements of each respective userdifferently.

The present invention provides a device and method for matching userswhose respective user's stored requirements and attributes match. Thematching process provides discretion for the user, as users are onlyalerted when a two-way match has been established. Furthermore, thematching process does not reveal the personal details of the user, asonly the requirements of the user are sent from the device. The matchingprocess is also entirely based on the matching of the respective users'attributes and requirements, and no artificial intelligence is required.Such devices obviate many of the problems associated with conventionaldevices.

For a better understanding of the invention, several embodiments of acommunications device and method of communication in accordance with theinvention will now be described with reference to the accompanyingdrawings in which:

FIG. 1 is a schematic diagram of an embodiment of a communicationssystem according to the present invention;

FIG. 2 is a schematic diagram of an embodiment of a communicationsdevice according the invention;

FIG. 3 is a schematic diagram of the memory structure of thecommunications device of FIG. 2;

FIG. 4 is a flow diagram illustrating a method of obtaining a two-waymatch between two devices according to the invention;

FIG. 5 is a flow diagram illustrating processes that occur after atwo-way match has been obtained between two devices in accordance withthe invention;

FIG. 6 is a table showing an example of an abbreviated user profilesuitable for use in an embodiment of the invention;

FIG. 7 is a schematic diagram of a further embodiment of acommunications system according to the invention; and

FIG. 8 is an illustration comparing the size and shape of the attributesand requirements of two users using symmetric profiles with two users ofasymmetric profiles.

FIG. 1 schematically illustrates interaction between two users, denotedUser A and User B, each carrying a portable electronic device 10.Although devices 10 are shown as application-specific portable devices,in FIG. 1, this need not be the case. Each device 10 could be integratedinto any existing portable device such as a mobile telephone, PDA,pager, or portable computer, such as a palmtop, notebook, or laptop.Although FIG. 1 illustrates communication between two substantiallysimilar devices, the invention is not limited in this way, and anapplication-specific version of the device 10 could be capable ofcommunicating with, for example, a compatible device integrated with amobile telephone, or even a compatible stationary unit such as a desktopcomputer

FIG. 2 schematically illustrates an application-specific portable device10 provided with a LCD screen 50, a keypad 60, an alert means 51, memory30, power source 100, and a transceiver 40 respectively connected to aprocessor 20. Other embodiments could employ alternative display means.The keypad 60, comprises a reset button 61, a blacklist button 62, aprobe button 63, a probe accept button 64, a probe reject button 65, andan on/off switch 66. Other embodiments may provide additional buttonsallocated to additional functions, or employ alternative user inputmeans. The alert means 51 comprises a set of LEDs 52, a speaker 54 and avibrator 55. Other embodiments may employ alternative alert means.

The power source 100 provides power to the device 10, and comprises abattery 101, backup battery 102, portable power source 103 and an ACpower inlet 104. The combination of the battery 101 and backup battery102 provide a means for storing power from the portable power source103. The AC power inlet 104 provides a means for re-charging theportable device 10. Other embodiments may employ alternative means ofstoring and supplying power to the device 10.

The transceiver 40 comprises a transmitter 41 and a receiver 42,respectively connected to an antenna 43, Bluetooth chips 90 and a timer80. The combination of the transmitter 41, receiver 42 and antenna 43use short range wireless communication technology to communicate withcompatible devices within range. There are few restraints on the type ofwireless communications technology which can be used with the invention,for example radio or microwave transmissions could be used. Although itwill be apparent that using short range communications has significantadvantages in some embodiments of the invention, other embodiments couldemploy long range communications technology. The embodiment illustratedin FIG. 2 uses Bluetooth technology to enable communication betweendevices. Although the communications flow described later is effectivelypeer-to-peer, the communications protocol on which it is built mayrequire that it be implemented within an underlying master-slaveparadigm.

The device 10 stores information comprising the attributes of the user,and the requirements of the user in one or more profiles, which arestored in the memory 30. The memory 30 could comprise any conventionalvolatile or non-volatile memory, or preferably a combination of the two.FIG. 3 is a schematic diagram of the structure of memory of the device10. The memory 30 comprises a profile store 31, a recent encounterscache 35, a blacklist cache 36, a log 37, and a user preference store39. Other embodiments of the invention could be provided with analternative memory configuration.

The user's attributes and requirements for each of the one or moreprofiles are stored in the profile store 31 of the memory 30. A“profile” is a self-describing data file that is made up of a series offields. Once populated by the user, a profile contains the data thatallows the device 10 to carry out a meaningful search. The device 10could store one or more profiles, including multiple instances of thesame profile type, which are populated with different criteria, to allowthe device to try and match the user based on a number of different setsof criteria.

The “attributes” are personal data of the user and contain a set ofcharacteristics of the user or something offered by the user. Theattributes for a given profile are stored in the attributes section ofthe profile. The “requirements” are the user's search criteria, anddefine which attributes relating to other users of compatible devicesthe user of the device 10 is seeking. The requirements are stored in therequirements section of the profile.

In the embodiment illustrated in FIG. 2, the user selects and configuresthe profiles to be stored in the device 10 using a personal computer(PC). For each type of profile selected, the user enters theirattributes and requirements on the PC via a suitable graphicalinterface. Once the selected profile has been populated with therelevant data, the user uploads the profile to their device 10, where itis stored in the profile store 31 of the memory 30. The user can uploadmore than one profile to the device, including multiple instances of thesame profile type. For example, a user may wish to find both a tennispartner and a squash partner at the same time. This user may well havedifferent attributes and requirements for the two sports, as theirproficiency level may differ greatly between the two.

The following are examples of profiles suitable for use with thisembodiment of the invention:

Relationship Finder Profile: the object of this profile is to aid a userto find a personal relationship. A user enters their personal details,which are stored in the fields of the attributes section. The user alsoenters the search criteria in the fields of the requirements section.The requirements section will contain fields including one that definesa desired level of commitment. This can range from casual sex, tofriendship, to marriage and children. The user may also enterinformation within a text field of a handle section of the profile. Thishandle information may be transmitted when a two-way match isestablished for this profile.

Sports Partner Finder Profile: the object of this profile is to aid auser in finding a suitable sports partner. A user enters the relevantdetails about themselves in the attributes section, together with theappropriate search criteria for finding others in the requirementssection. The requirements section contains information such as theparticular sport, how often and when the user would like to play, theuser's competency level, etc.

The device 10 connects to the PC via the transmitter 41, using the shortrange communications capability of the device 10. Such an embodimentrelies on the PC being suitably equipped to receive short rangecommunications sent by the device. In other embodiments of theinvention, the connection between the device 10 and a PC could beestablished by way of a physical connection, which would require thedevice 10 comprising a suitable PC interface.

In order to select and configure the profiles for use on the device 10,the PC is provided with suitable editing and uploading software. Thissoftware could be supplied with the device 10, and comprise a set ofofficially endorsed profiles. Alternatively, the user may use the PC toconnect to the Internet, and download new profiles from a suitable webserver. Alternatively profiles could be downloaded from an email or MMSattachment. These downloaded profiles could be officially endorsed bythe suppliers of the device 10, or created by third parties.

Although the populating and editing of profiles has been discussed withreference to the use of a PC with access to the Internet, the inventionis not limited in this way. A laptop computer, workstation, server,office terminal or PDA could all be suitable for editing and uploadingprofiles to the device 10. Furthermore, in embodiments which areintegrated into other devices, such as mobile telephones or PDAs, thedownloading and editing of the profiles could be performed using theintegrated device alone. In such embodiments, the use of the transceiver40 or suitable PC interface to connect to a PC would not be required,but may be optionally desired. It would also be possible to configureeven an application specific embodiment of the device to accept aremovable data carrier, such as a solid state, optical or magneticstorage media, upon which could be pre-loaded a selection of profiles.

An indication of the profiles stored in the memory 30 of the device 10is displayed on the LCD screen 50. The user uses the keypad 60 to selectone or more profiles that they wish to be made active from thosedisplayed. Once active, the name of the profile may be displayed on theLCD screen 50. Activating a profile indicates to the processor 20 tocommence the process of trying to obtain a match. The process of tryingto obtain a match will be discussed in more detail in relation to FIG.4.

Each device 10 has a unique Identification Number (ID) that cannot bealtered by the user, and is stored in the memory 30. Optionally, theuser can enter a “handle” for each profile, which is stored in thehandle section of the profile. The handle section of a profile comprisesat least one field, and a handle may comprise a string of characters andcould take the form of a name or nickname, or details about a matchbetween two users. If present, the handle is transmitted by the device10 to users of compatible devices on the establishment of a match. Thehandle is stored in the memory 30, and could be entered via the keypad60 or edited on the PC and uploaded to the device 10. If a handle isentered by the user, its transmission to other users is optional, andcould be turned off by the user using the keypad 60 at any time.

If the user carries or wears the device 10, containing active profiles,the device 10 actively and unobtrusively attempts to seek out matcheswith compatible devices using the short range communications capabilityof the device 10.

The user can change the profiles that are currently active to suit theirimmediate needs by use of the keypad 60. For example, a user who haspreviously activated the Relationship Finder Profile may wish to disablethis profile while they at work. Similarly, a user who activated theSports Partner Finder Profile may wish to deactivate this profile once asuitable partner has been found.

Every profile is subject to a predetermined active period, and thedevice 10 comprises a timer 80 that instructs the processor 20 todeactivate every profile after the predetermined period has elapsed.This prevents outdated profiles from being kept active. Thepredetermined period for each profile can be edited on the keypad 60 ofthe device 10, or on the PC prior to uploading the profile to thedevice.

In order to further facilitate the activating and deactivating ofprofiles, the user can also set the timer 80 to instruct the controller20 to activate or deactivate stored profiles at predetermined times ofthe day or week. This could allow the user to set up a profile diary tosuit their needs, and could give the user the capability of automatingthe selection of active profiles. The predetermined times of the day orweek could be edited on the keypad 60 of the device 10, or on the PCprior to uploading the profile to the device 10. These timed settingsare stored in the profile and could be overridden at any time by theuser, for example by using the keypad 60.

When the device 10 establishes a match with a compatible device, thedevice 10 enters matched mode and alerts the user to the match. The usercould be alerted to the match by any user-determined combination of oneor more flashing LEDs 52, a message on the display 50, an audible alertor a vibrating alert. These and other user preferences are stored in theUser Preferences Store 39 of the memory 30.

If selected, the audible alert is provided by the speaker 54, and couldtake the form of a ring tone or similar alert. The vibrating motion isprovided by the vibrator 55, which is of a conventional sort, such asthose common in mobile telephones. The user selects their alertpreference, which could depend on their current situation, by means ofthe keypad 60. For example, on a crowded train a user might prefer toselect a silent, vibration-only alert. The user of the compatible deviceis similarly alerted to the match, at substantially the same time as thefirst user.

Once a match has been established, the user's optional handle istransmitted to the compatible device with which a match has beenestablished, if desired by the user. In the ensuing matched mode,information regarding the match, though not the personal details thatcomprise the attributes of the user of the compatible device (which havenever been transmitted), is displayed on the LCD screen 50. This matchinformation can be optionally stored in the log 37 of the memory 30 ofthe device 10 for later review on the device 10. Optionally it could beuploaded to the user's PC, where the data could be analysed.

The method by which the device 10 obtains a match with a compatibledevice will now be described in detail with reference to FIG. 4. Priorto step S1, the user selects and activates one or more profiles storedin the memory 30 of the device 10, in the manner such as that detailedabove.

In the following description it is assumed that the steps represented inFIGS. 4 and 5 are performed by both the device 10 and the compatibledevice during the course of the dialogue.

At step S1 the device 10 is in a state in which it is polling for othercompatible devices. The controller 20, in conjunction with the timer 80,instructs the transmitter 41 to send a “HALLO” message at predeterminedfrequent intervals. A HALLO message is a short message string thatcontains information about the device it was sent from, and includes theunique ID number of the device 10. The unique ID of the device 10 isincluded in every message that it transmits. This enables the device 10and the compatible device to maintain exclusive dialogue with eachother, even if other such devices are in range. During the polling statethe receiver 42 is continually operable to detect any HALLO messagessent from compatible devices in range. Polling represents the base stateof the device 10, and the device returns to polling if any stage in theprocesses detailed in FIG. 4 or 5 times-out. This could be due to acommunications disruption or the compatible device moving out of range.The device 10 also returns to polling if the user resets the device 10at any point, for example by means of the reset button 61 on the keypad.

If the receiver 42 receives a HALLO message from a compatible deviceduring polling, it will instruct the processor 20 to enter into anexclusive dialogue with the compatible device that sent it. The receivedHALLO message will contain the ID of the compatible device, which theprocessor 20 compares, at S2, with the received ID of the compatibledevices stored in the Recent Encounters Cache 35 and the Blacklist Cache36 of the memory 30.

The Recent Encounters Cache 35 comprises a list of IDs of compatibledevices that the device 10 has communicated with recently. The purposeof this cache is to prevent the device 10 from repeatedly attempting toestablish a match with the same compatible device. This could prevent,for example, the devices of two people in the same train carriage fromcontinually entering into exclusive dialogue with each other. Thepresence of the Recent Encounters Cache also ensures that where manycompatible devices are in range of each other, every device 10 willattempt to match with every other compatible device. The RecentEncounters Cache 35 comprises the most recently encountered IDs ofcompatible devices. When the Recent Encounters Cache 35 becomes full,the oldest entry will be purged. Entries in the Recent Encounters Cache35 could also be purged after a predetermined time has elapsed.Furthermore, the user could purge the Recent Encounters Cache 35manually.

The Blacklist Cache 36 contains a list of the IDs of compatible devicesthat the user of the device 10 has blacklisted after a match has beenestablished. The contents of the Blacklist Cache 36 could be purged inthe same way as for the Recent Encounters Cache 35 described above.

If the received HALLO message contains an ID of a device found in eithercache, the device 10 proceeds to step S3, where the device breaks offthe exclusive dialogue with the compatible device, and sends a “GOODBYE”message to the compatible device. The device 10 then proceeds back tostep S1, where it resumes polling. The GOODBYE message informs thecompatible device that the exclusive dialogue has been broken off, andnot to expect further communications.

If the received HALLO message contains an ID of a device that is notfound in either cache, the device 10 sends a “READY” message to thecompatible device at step S4 a. The READY message informs the compatibledevice that its HALLO message has been received, and that the device 10has not found the ID of the compatible device in its caches.

At step S4 b, the device 10 will have received a message from thecompatible device. If the compatible device found the device ID in itscaches at step S2, then the device will have a received a GOODBYEmessage. This will result in the device 10 proceeding to step S7.

If the ID of the device 10 was not found in either cache of thecompatible device, the device 10 will have received a READY message.Both devices will now be in a ready state, and the device 10 proceeds toS5.

At S5 the device 10 and the compatible device have established anexclusive dialogue. Both devices then send an Active Profile list to theother device. The Active Profile list comprises a sorted list of thoseprofiles currently active. The profiles could be sorted in any way, aslong as it was consistent for compatible devices.

At S6, the processor 20 compares the Active Profile lists of bothdevices and generates a sorted list containing any active profiles thatthe device 10 and the compatible device have in common. If no commonactive profiles are detected, the processor 20 adds the ID of thecompatible device to the Recent Encounters Cache 35 at S7, sends aGOODBYE message at S3, and the device 10 returns to polling.

If one or more common active profiles are detected, the device 10proceeds to S8. The processor 20 selects the first/next profile on thelist. The device 10 then sends the user's requirements that are storedin the requirements section of the selected active profile to thecompatible device. The compatible device similarly sends therequirements of the selected active profile of its user at substantiallythe same time. At no point in the matching process does either devicesend the personal details of the user that are stored in the attributefields of the active profiles. This means that the security of thesystem is high, and the most a suitably equipped snooping device couldintercept is search criteria in the form of requirements. Thisinformation would be addressed by a unique device ID, and could not beeasily traced back to the user who created them.

Once the device 10 has received the requirements of the compatibledevice, they are stored in the memory 30. At S9, the processor 20compares the received requirements with the fields in the attributessection of the selected active profile, in order to ascertain whetherthey match.

If all the received requirements match the user's stored attributesthen, at S10, the device 10 sends an I_MATCH message to the compatibledevice. The device 10 then waits for a corresponding message from thecompatible device. The device 10 will then either receive an I_MATCHmessage or an I_DON'T_MATCH message, and proceed to S11.

If an I_MATCH message is received from the compatible device, then thesent requirements of the device 10 match the stored attributes of thecompatible device. If neither device has multiple active instances ofthe selected active profile (S11 c), a two-way match has thus beenestablished (S12) for this profile. The more complex case wherein one orboth devices have multiple instances of the profile will be discussedlater.

If an I_DON'T_MATCH is received, then the sent requirements of thedevice 10 do not match the stored attributes for any active instances ofthe profile in the compatible device. The device 10 then logs thedetails of the failed match at S11 b and proceeds to S14.

If, at S9, less than all the received requirements match the storedattributes for each active instance of the profile, the device 10 willsend an I_DON'T_MATCH message to the compatible device (S13). Then,regardless of whether the device 10 then goes on to receive an I_MATCHor an I_DON'T_MATCH message, the device 10 proceeds to S14.

At S14 the controller 20 checks if there are any more common activeprofiles on the sorted list. If there is another common active profilethe device 10 returns to step S8, and sends the requirements of the nextcommon active profile from the sorted list. The device 10 then goesthrough the process of checking if the received requirements match thestored attributes, following the steps detailed above.

If there are no more common active profiles on the list, the device 10proceeds to step S7, where the ID of the compatible device is added tothe Recent Encounters Cache 35, a GOODBYE message is sent (S3), and thedevice 10 returns to polling.

When either the device 10 or the compatible device has multiple activeinstances of a particular profile special consideration is required.Multiple active instances of a profile are dealt with as a singlematching process. When a device 10 has x active instances of a profile,then at S5 when the device 10 sends its active profile list to thecompatible device, that profile will be included in the Active Profilelist x times. If the compatible device has y active instances of thesame profile, where y is greater or equal to one, then the profile iscommon to both devices, and at S6 the processor 20 will include the IDof the common profile only once in the common active profile list thatit generates.

At S8, when the device 10 reaches this profile in the sorted commonprofile list, x sets of requirements will be included in therequirements transmission from the device 10 to the compatible device,and y sets of requirements will be included in the requirementstransmission from the compatible device to the device.

At S9, the device 10 will compare each set of received requirementsagainst each set of attributes held by the device 10. In the case whereno matches are found for this profile in any of its active instances,the device 10 sends an I_DONT_MATCH message at S13. In the case whereone or more matches are found for this profile in one or more of itsactive instances, the device 10 proceeds to S10 and sends an I_MATCHmessage, comprising a 2-dimensional matrix of match/no_match flags inwhich the columns are indexed on the instances of the profile held bythe device 10. In the case where the compatible device finds one or morematches for this profile type, the compatible device will similarly sendan I_MATCH message comprising a matrix, in which the columns of thematrix are indexed on the instances of the profile held by thecompatible device. Receipt of this message will cause the device 10 toproceed to S11 c via S11. As the received I_MATCH message is of thespecial form required for multiple active instances of a profile type,the device 10 proceeds to S11 d.

At S11 d, the device 10 will transform the received matrix so that itcan be compared with the matrix built by the device at S9. Thiscomparison will identify any and all two-way matches for this profiletype. At S11 e, if there are no two-way matches, the device will proceedto S11 b and log details of the failed match. If there are any two-waymatches, the device 10 and the compatible device will each proceed toS12, and a Two-Way Match has been established.

Once the device 10 has established a two-way match, the device willenter a matched mode. The establishment and operation of this mode willbe discussed below in more detail in relation to FIG. 5, however beforethis, a more detailed example of how the processor 20 processes the datain the selected active profile in order to ascertain whether theprofiles of the respective users match will be discussed with referenceto FIG. 6. FIG. 6 shows an abbreviated example of two RelationshipFinder Profiles, as respectively populated by the user of a device 10(User A), and a user of a compatible device (User B), as discussed abovein relation to FIG. 1.

In this example, User A is a woman seeking a personal relationship andUser B is a man similarly seeking such a relationship. Both userspossess a device 10, of the kind illustrated in FIG. 2, or a devicecompatible with such devices.

Prior to the meeting, User A connects her device 10 to her PC, selects aRelationship Finder Profile from the list of profiles stored on her PC,and populates the data according to her attributes and requirements.These data are then uploaded to the profile store 31 of User A's device10, and the Relationship Finder Profile activated. Prior to the meeting,User B has similarly populated, uploaded, and activated a RelationshipFinder Profile.

A profile such as the Relationship Finder Profiles illustrated in FIG. 6comprises a set of attributes and requirements fields of variouspredetermined types. The types of data possible in each field, andexample field structures will be discussed in more detail later. If andonly if every attribute field matches the corresponding receivedrequirement field for a particular profile, will the whole profileresult in a match.

As can be seen in FIG. 6, User A is a 27 year old female, who is 5′8″with brown hair. She has O-levels/GCSEs, A-levels and a UniversityDegree, and has not entered her salary. She would consider being matchedwith other users who wanted a relationship based upon the commitmentlevel “Good Friendship”, “Long Term Partner” or “Casual Sex”. These datafields comprise information personal to User A, and are stored in theattributes section of User A's Relationship Finder Profile.

User A is interested in meeting a male who must be between 25 and 30,have a University Degree, be no shorter that 5′9″ and must be interestedin a relationship with commitment level of “Casual Sex”. These datafields comprise the requirements of user A, and are stored in therequirements section of User A's Relationship Finder Profile.

User B is a 31 year old male, who is 6′1″ with black hair. He hasO-levels/GCSEs, A-levels and a University Degree, and a salary of £30K.He would consider being matched with other users who wanted arelationship based upon the commitment level “Long Term Partner” or“Casual Sex”. These data comprise information personal to user B, andare stored in the attributes section of User B's Relationship FinderProfile.

User B is interested in meeting a female who must be between 20 and 30,be no taller than 6′1″, have any colour hair except grey, and must beinterested in a relationship with commitment level of “Casual Sex” or“Long Term Partner”. They must also earn a minimum of £15K if they haveentered their salary, but as user B set the mandatory flag to equal‘False’ in the salary field non disclosure of salary will not lead torejection. These data comprise the requirements of user B, and onceentered on user B's PC are uploaded to user B's device 10 and stored inthe requirements section of User B's Relationship Finder Profile.

Considering User A's profile, all the received requirements fields fromUser B match the stored attributes fields. Therefore at step S9 of FIG.4, the controller 20 of User A's device would instruct the transmitter41 to send an I_MATCH message to User B's device.

However, User A's device will not enter matched mode unless a two-waymatch is established. As all User B's attributes fields match thereceived requirements from User A's device, User B's device will send anI_MATCH message to User A's device. User A and User B will have thenboth sent and received I_MATCH signals, which will result in a Two-wayMatch being established (S12), and both devices will enter matched mode.

The steps following the establishment of a two-way match will now bediscussed with reference to FIG. 5. On the establishment of a two-waymatch the device 10 proceeds to alert the user at step 17. All thedescribed matching steps prior to S17 would have been invisible to theuser. The user is only alerted once a two-way match has beenestablished. As discussed above, the user alert could take many forms,and in particular could be a combination of an audible alert produced bythe speaker 54, a vibrating alert produced by the vibrator 55, and avisual alert on the LCD screen 50.

At S16, the device 10 then adds details of the matched profiles to theTwo-Way Match log, located in the log store 37 of the memory 30. Thisrecords the details of the match, so that they can be later examined by,for example, uploading the data from the two-way match log to the user'sPC. This could include information such as the name of the matchedprofile and details of the requirements that were sent by the compatibledevice.

At step S15 the device then proceeds to send a WE_MATCH message to thecompatible device. The WE_MATCH message will contain the contents, ifany, of the handle section of the matched profile. The device 10 willreceive a corresponding WE_MATCH message from the compatible device andwill proceed to S21. The content and format of the WE_MATCH messagecould depend on the selected profile type. In cases where the device orcompatible device has multiple active instances of the same profile, theWE_MATCH message could contain handle details for all two-way matchesidentified.

On receipt of the WE_MATCH message, the user is then presented with anyadditional pertinent information, as supplied by the optional fields ofthe handle section of the compatible device. This information could bedisplayed on the LCD screen 50 and could be appended to the two-waymatch log.

At any time while in Matched Mode (S21), or Probe mode (S27) the user ofthe device 10 can blacklist the user of the compatible device bypressing the blacklist button 62 on the keypad 60 of the device 10. TheID of the compatible device is then added to the Blacklist Cache 36 ofthe device 10 at stage S20. The device 10 then returns to the pollingstate via step S3, where a GOODBYE message is sent.

A user may want to blacklist another user for a number of reasons. Forexample, once a physical meeting has occurred between the two users, theuser of the device 10 may decide that they never want to be matchedagain with the user of the compatible device, based on any profile orset of requirements.

Matched mode (S21) could be cancelled at any time by use of the cancelbutton 67 on the keypad 60 (S22). This causes the device to proceed tostep S7 of FIG. 4, and add the ID of the compatible device to the RecentEncounters Cache 35.

While in matched mode, both users can try and physically locate eachother. In embodiments in which a short range communications technologyis used, physically locating the user of the compatible device may betrivial due to the relatively small distances involved. However, thelocation of the other user might not be trivial, if for example, theusers are in a crowded area such as a night-club, or busy street.Similar difficulties in locating each other may be experienced by usersif a long range communications technology is used. In such situations,the optional probe facility may be employed to assist the actualphysical meeting of the users.

In embodiments where the probe facility is present, the user may receivea Probe Request message from the compatible device. This could occur ifthe user of the compatible device is experiencing difficulties inlocating the matched user of the device 10. The user is then alerted tothe probe request (S23) by means of a probe alert, which could compriseany combination of an audible alert produced by the speaker 54, avibrating alert produced by the vibrator 55, and a visual alert on theLCD screen 50, or one or more flashing LEDs. At Step S24, the user canthen accept, reject or simply ignore the probe request. If the userwishes to reject the probe request, the Probe reject button 65 on thekeypad 60 is pressed, the device 10 sends a Probe Reject message (S28),and the device 10 returns to matched mode (S21).

If the user wishes to accept the probe request, the Probe Accept button64 on the keypad 60 is pressed. The device 10 then sends a ProbeAccepted message to the compatible device at S25. The device 10 willthen progress to S27 and both devices will initiate probe mode.

Similarly, the user can try and enter probe mode by pressing the Probebutton 63 on the keypad 60 while in matched mode (S21). The device 10then sends a Probe request message (S26) to the compatible device, andthe user of the compatible device can decide to send a Probe Acceptmessage, a Probe Reject Message, or do nothing.

If a Probe Accept message is received by the device 10 at S29, thedevice 10 initiates probe mode and progresses to S27. If a Probe Rejectmessage is received at S29, the device 10 returns to Matched Mode (S21).If the user of the compatible device ignores the probe message, then thedevice 10 will remain at S26 until the device 10 times out, at whichpoint the device 10 returns to Matched Mode (S21).

In probe mode both devices will employ audible indication, visualindication, vibrating indication or a combination of the three to allowthe users to locate each other. The audible indication could take theform of a probe indicator tone, which could be suitable sound to audiblyfacilitate the physical meeting of the users. The visual indicationcould take the form of one or more flashing probe indicator lights. Thevibrating indication could take the form of a vibration produced by thevibrator 55.

Optionally the device 10 could allow the pressing of the Probe button 63while in Probe mode (S27) to cause the compatible device to indicate afurther probe alert to its user. Repeated pressing of the Probe button63 could allow for repeated probe alerts. The repeated probe alertscould allow each user to locate each other easily.

In integrated embodiments, such as devices integrated into mobiletelephones, the user could be able communicate directly with the user ofthe compatible device. This could take the form of sending text messagesover the wireless network, or similarly making a voice call.

In addition to the described two-way match log, the device 10 couldstore details of every interaction with a compatible device, includingthose that failed to produce a match, in the log 37. This data could beuploaded to the user's PC for periodic analysis of number of encounters,number of matches, number of non-matches, and the specific fields inspecific profiles causing non matches. Such data could allow a user toamend their requirements or attributes to try and encourage morematches.

Even if a two-way match has been established for one active profile,while in Matched Mode (S21), the device 10 and the compatible devicewill continue to process any remaining common active profiles (notshown). The device 10 and the compatible device will proceed through thecommon active profile list, exchanging and checking requirements for anyadditional matches. Any additional two-way matches established in thisway will be indicated to the user in the manner described above.

The embodiments of the invention thus far described have employed amethod of matching of users based on profiles that treat all users ofcompatible devices in the same way. Such profiles are termed “symmetricprofiles”, as matching is attempted based on a set of requirements andattributes fields that are equal in shape and size as between bothusers, i.e. the users of the device and-the compatible device will haveboth populated the same set of attributes and requirements fields.

A symmetric profile comprises at least one requirement field for everycorresponding attribute field. Furthermore, there will be one instanceof the attributes section and one instance of the requirements sectionper populated profile. The list of attribute fields will not necessarilybe the same as the list of requirements fields, and for example tworequirements could be matched against a single attribute (e.g. aninclude list and an exclude list).

However, in other embodiments of the invention, one party's requirementsmay be less restrictive than the other's. For example, a house hunterwho wishes to buy a house will be seeking a specific type of property,based on strict criteria. This could include information such as price,number of rooms, and location of the property. The house hunter could beinterested in being matched with every property on the estate agent'sbooks that match their house requirements.

An estate agent may have many properties on their books, and wish to bematched with every user who is looking to buy or rent one of theirproperties. In order to satisfy the needs of both the house hunter andthe estate agent, asymmetric profiles can be used. Asymmetric profilescontain a field to distinguish the finder of something from the providerof something.

Asymmetric profiles are distinguished from symmetric profiles by havingtwo variants of each profile, one for the finder and one for theprovider. For every attribute field in the provider variant there is atleast one corresponding requirement field in the finder variant. Thesame is true of the attributes in the finder and the requirements in theprovider, but these will generally be minimal. The finder-providernature of asymmetric profiles contrasts to the finder-finder nature ofsymmetric profiles, as illustrated in FIG. 8. For the symmetric profile:Finder A and Finder B both have attributes fields and requirementsfields of the same size and shape. For the asymmetric profile: Finder Ahas only one attribute field, whereas Provider B has multiple instancesof the attributes field, which is of a different size and shape.Similarly, Finder A's requirements field is of a different size andshape to Provider B's requirements field.

A key characteristic of an asymmetric profile is that the provider partycan populate multiple instances of the attributes section in a profile.For example an Estate Agent can populate as many attribute sets as thereare properties on their books.

The following are examples of asymmetric profiles:

Property Finder Profile: the object of this profile is to aid a user tofind a suitable property to rent or buy. A user enters their propertyrequirements into the requirements fields. These could range fromwhether they are interested in a flat or a house, the number ofbedrooms, and a price range, to far more specific preferences such as:open plan, modern, rear facing master bedroom, decorative order. As theuser becomes proximate an Estate Agent, or vendor, equipped with acompatible device, the user will be alerted to any properties that matchtheir requirements.

Book Finder Profile: the object of this profile is to aid a user to finda specific book or books that they are looking for. For example, a usercould enter the ISBN numbers or Titles or Authors of the book or booksthat they are looking for, and as the user becomes proximate a suitablyequipped bookstore, they are alerted if any of their listed books are instock. Furthermore, they may be provided with additional details, suchas the precise location of the book or books within the store and its ortheir price.

As discussed, asymmetric profiles are typically used in the situation inwhich one user is a finder, and the other is a provider. In the exampleof the Property Finder Profile, the estate agent is the provider, andthe house-hunter the finder. For the Book Finder Profile, the bookselleris the provider, and the book shopper the finder.

FIG. 7 illustrates the situation of communication between two compatibledevices according to an embodiment of the invention, respectively ownedby a potential customer and a vendor. The potential customer is thefinder and the vendor the provider. The potential customer could possessa portable application-specific device 10 or a device integrated with anexisting device such as a mobile telephone or PDA.

Similarly, the vendor could also possess such a portable device 10.However, it would be practical for the vendor to possess a fixedcompatible device 200 located in their shop or workplace. The fixedcompatible device 200 could comprise a PC, workstation, server, orterminal comprising suitable hardware and software adapted tocommunicate with the portable devices of potential customers. The fixedcompatible device 200 could furthermore comprise many of the features ofthe portable device 10, described with reference to FIG. 2. Thefunctions of the display 50, alert means 51, memory 30 and keypad 60could all be performed by existing features of the vendor's PC,workstation, server, or terminal.

The fixed compatible device also comprises a transceiver, to allow forcommunication with compatible devices. This could be in the form of aninternal or external unit. The transceiver could be similar in design tothose comprised in the application-specific or integrated devicespreviously described with reference to FIG. 2.

The fixed compatible device 200 comprises suitable software to allow thevendor to store and populate profiles suitable for use with thisembodiment. Although, it is envisaged that the profiles used in thisembodiment are of the asymmetric finder-provider type, this embodimentof the invention is not limited in this way, and there is no reason whyeither the provider or finder could not simultaneously employ a mixtureof symmetric and asymmetric profiles.

For example, if a user of a portable device 10 wishes to find a propertythey may populate and upload the Property Finder Profile to their devicein the manner described above. This could involve the use of the user'sPC, if the user possesses an application-specific device. The user couldthen activate the Property Finder Profile and go about their daily life.

With the Property Finder Profile active, the user's device 10 activelyand unobtrusively attempts to seek out compatible devices with theProperty Finder Profile similarly active, whose attributes match theuser's requirements, using the short range communications capability ofthe device 10.

The process by which the devices establish exclusive dialogue in thisembodiment is generally similar to that previously described withreference to FIGS. 4 and 5. However, as the Property Finder Profile isan asymmetric profile, there are important differences in the matchingprocess.

In a symmetric profile, a match will not be established unless the sentrequirements of the user match the stored attributes of the user of thecompatible device, and the sent requirements of the user of thecompatible device match the stored attributes of the user. Thiscorresponds to a two-way match. Similarly, when using an asymmetricprofile, neither device will enter the matched mode until a two-waymatch has been established. However, there are different criteria for anI_MATCH message to be sent from the device 10 of the user designated thefinder, and the device 200 of the user designated the provider.

In the example of a house hunter wanting to buy a house, the PropertyFinder Profile stored on the house hunter's device 10 will contain afield that indicates that this user is designated a finder.Correspondingly, the Property Finder Profile stored in the estateagent's device 200 will contain a field that indicates that the estateagent is designated the provider.

The requirements section of the house hunter's Property Finder Profilestored on their device will contain detailed information about theirproperty requirements. The requirements section of the estate agentsdevice 200 will contain information indicating that they are interestedin obtaining a match with any house hunter who is interested in matchingwith one of their properties.

If the house hunter is interested in buying a 2 bedroom house with agarden, the house hunter's device 10 will try and obtain a match withthe device 200 of any estate agent who has such a house or houses in theattributes section of their Property Finder Profile. If the house huntercomes into range of an estate agent's device 200, the house hunter'sdevice 10 will enter into dialogue with the estate agent's device 200.

The caches of each device will be checked, and if the IDs of bothdevices were not present in either cache of either device, the sortedlist of active profiles will be exchanged. As discussed, the matchingprocess is generally similar to that described above for symmetricprofiles. However, the matching process for the provider, in this casethe estate agent, may have to loop through checking a single set ofreceived requirements against multiple stored attribute sets(corresponding to all their properties).

If the estate agent has a suitable property, an I_MATCH message will besent by the estate agent's device 200. If the estate agent has nosuitable properties, an I_DON'T_MATCH message will be sent. In the caseof the Property Finder Profile, the requirements of the estate agent areminimal, as they wish to match with as many house hunters as they can.Hence, the house hunter's device 10 will send an I_MATCH signal.

If both devices have sent and received I_MATCH signals, a two-way matchhas been established, and both devices enter matched mode. Both deviceswill then send WE_MATCH signals, which may vary from profile to profile,and could include the profile's handle. For example, in the case of theProperty Finder Profile the handle sent from the estate agent's device200 could comprise a contact telephone number, web address or locationof the estate agent, together with some details or reference numbers ofall the matched properties.

The estate agent could have multiple instances of the Property FinderProfile active to correspond to every property on their books. Morepreferably, all of their properties could be listed as multipleinstances of the attributes section of one profile. As discussed, theability to include multiple instances of the attribute data within theattributes section of a provider's profile is a key feature ofasymmetric profiles.

In the case of the Book Finder Profile, the finder would be a potentialbook purchaser and the provider a book seller. For example, the findercould populate the Book Finder Profile with data corresponding to thebooks they are interested in buying, and possibly at what price. Theprovider could list all the books they currently have in stock withtheir prices.

If the book purchaser passes within range of the book seller, then therespective devices will enter into a dialogue. If the book seller stocksthe book or books that the potential book purchaser is interested in,then the book seller's device 200 will send an I_MATCH signal. As theBook Finder Profile is of the asymmetric type, the book seller isinterested in matching with any potential book purchaser, and hence thebook sellers sent requirements will be minimal. Hence, the bookpurchaser's device 10 will send an I_MATCH message. A WE_MATCH messagewill be sent from both devices. The handle within the WE_MATCH messagesent from the book seller could contain information such as the priceand location of the book within the store.

The two examples of asymmetric profiles discussed would both normally beassociated with the situation in which the requirements sent by theprovider will be minimal. However, this will not always be the case, anexample being a Pet Finder Profile run by a Veterinary Hospital. Forexample, a finder could only be qualified for a match if they had agarden or could afford Veterinary bills.

A further embodiment of the invention could comprise an adaptation ofthe portable device 10, described with reference to FIG. 2, especiallyfor the use of children.

This embodiment can be adapted to be only operable with profilesdesigned especially and specifically for children. This would ensurethat the device meets the particular needs of children. An example of aprofile suitable for use with the children's embodiment is given below:

Swap Shop Profile: the object of this profile for use with thechildren's embodiment is to aid a user to find another user to make aswap with. A user enters the details of what items they are wishing toswap, which are stored in the attributes section. The user also entersthe search criteria in the requirements section, which contains itemsthat they are interested making a swap for. This profile could be usedto swap trading cards or other children's collectable times.

Friend Finder Profile: The object of this profile for use with thechildren's embodiment is to aid a user to initiate a friendship withanother user. A user enters their personal details, which are stored inthe attributes section. The user also enters the search criteria in therequirements section, including what sort of user they are interested inmaking friends with. This profile could function as a scaled downchild-friendly equivalent to the Relationship Finder Profile used withthe adult embodiments.

In order to provide extra safeguards against unscrupulous use of devicesconcerning children, only profiles designed specifically for use withthe children's profile will run on the children's embodiment. Adultorientated Profiles such as the Relationship Finder Profile areinoperable on the children's embodiment. Certain child friendlyprofiles, such as the Book Finder Profile, can be allowed to be used onall embodiments of the invention, including the children's embodiment.

For this to be implemented, the hardware of devices for use with thechildren's embodiment are locked to only store profiles that have apredetermined children's embodiment flag encoded in the profile ID. Thisflag comprises a number of bits of the Profile ID, which are reserved asprofile “Embodiment Identifiers”. One bit is used to identify an “Adult”embodiment of a profile, while another bit is used to identify a“Children's” embodiment of a profile. Further bits may be reserved forother possible characteristics. Any profile with the adult bit set willfunction on any adult embodiment of the device. Similarly, any profilewith the children's bit set will function on any children's variant ofthe device. Some profiles, for example the Book Finder Profile couldhave both of these bits set and would therefore function on both adultand children's variants of the device. As these bits are containedwithin the Profile ID, any hacking of this Profile ID will make it adifferent profile and hence will not match with the un-hacked profileID. This provides a safeguard against unscrupulous use of the children'sembodiment.

The remainder of the hardware used in the children's embodiment issubstantially similar to the application-specific or integrated portabledevices described above. The matching process is similar to thatdescribed above, only allowing children's profiles to be matched againstother children's profiles. Other restrictions could be placed on the useof certain profiles on certain user's devices. For example, a device 10issued by an employer to its employees could be set to accept only workrelated profiles.

Aside from the enforced limitations associated with the children'sembodiment, there are in general no limits to the type of data that aprofile can be populated with. As discussed, profiles areself-describing data files. The self-describing nature of the profilesallows new varieties of profiles to be created and distributed to usersof existing devices. By connecting to the Internet, either via a PC oron an integrated device, a user may download new profiles for use withtheir device.

New profiles could be created by 3^(rd) parties, who could develop anddistribute their own profile types. While these 3^(rd) party profilescould be highly complex, they could be very simple. In its simplest forma profile could comprise nothing more than the unique ID of the profile.In such a case, a two-way match would be established when any twodevices with such a profile active attempted to match.

An example of a 3^(rd) Party profile could be a Conference Profile. Theorganizers of a Conference could include on their conference web page alink to download their 3^(rd) Party Conference Profile. The uniqueprofile ID of this profile could, by itself, serve as a means ofidentifying other attendees of the conference. In this case, attendeesof the conference would be able to download the Conference Profile totheir devices and activate it to help identify and socialize with otherconference attendees as they wander around the town or city in which itis located.

Such 3^(rd) party Profiles could easily be extended to other areas. Anightclub might, for example, provide a specially tailored RelationshipFinder Profile that allows its patrons to socialize in novel ways. SuchProfiles could also serve to enable special competitions and otheractivities based on the contents of predetermined fields within theprofile.

Although it has been stated that an advantage of the present inventionis that it does not rely on a centralised system to store details of theusers and perform matches, embodiments of the invention could beintegrated within a centralised infrastructure. This centralisedinfrastructure could provide a location aware telecommunicationsnetwork, for example, using 3G communications technology. Using such acentralised infrastructure, the device 10 could be used to populate andselect the profiles and alert users to the matches. A central databasecould store the profiles (by upload from the device) and perform matchesbased on the location of the users. The location information of eachuser could be relayed to the central database by the location awaretelecommunications network.

An example of a data structure for the profiles discussed above will nowbe described. In this example, the profile is made up of a collection offields, and each profile type comprises at least the following mainelements: the header, attributes, requirements, and the handle.

All Fields will have the following characteristics, the function ofwhich will sometimes depend on the context in which they appear, i.e.whether the field is located within the attributes section or therequirements section of the profile. Table 1 shows an example fieldstructure. TABLE 1 Field Structure. Context Characteristic AttributesRequirements Field Type Identifies the type of field, Same as attributesso that device and the user interface know how to process it Field IDIdentifies this attribute field Contains the Field ID uniquely withinthe Profile of the attribute against which it is to be compared toestablish a match Field Name Name of this field, as Same as attributespresented to the owner in the context of this profile Mandatory FlagIdentifies this field as When set to True, do Mandatory or Optional(i.e. NOT match with users whether or not the user who have not enteredMUST supply data) any data for this field. When set to False, ALWAYSmatch with users who have not entered any data for this field. IntrinsicValues This defines the types of Same as attributes values this fieldtype supports - for example, with a Boolean field type, the intrinsicvalues would be True or False Selected Values The values selected by theSame as attributes owner populating this profile Finder/Provider flagFor Asymmetric type Same as attributes Profiles, this is used to specifyif this field is valid for population by the finder party, the providerparty, or both parties. For all other (i.e. symmetric) profiles, thiswill always be NULL. Type Specific . . . . . . Characteristics . . . . .. . . . . . .

The Field ID is used to uniquely identify a field within the attributessection of a profile, and is used by all of the correspondingrequirements fields to identify the relevant attributes fields.

For symmetric profiles, the attributes and requirements elements of aprofile are built from a set of fields that are mirrored for both users.

For asymmetric profiles, such as the Property Finder Profile, theattributes and requirements sections of the profile are substantiallydifferent.

The header of the profile includes the profile ID that uniquelyidentifies the profile type. The use of profile IDs allows a device toidentify common active profiles sent by compatible devices, when lockedin exclusive dialogue. The header can also be used to flag if theprofile is symmetric or asymmetric, or if the profile is not suitablefor use by children. This is preferably encoded within the profile ID asa number of bits comprising an embodiment identifier. In order for everyprofile to be readable on every device (subject to the restrictionsassociated with children) the header has a predetermined andnon-configurable format. Therefore, any user created profile will becapable of being processed on any device according to the invention. Theprofile header can also be used to store the timing information thatindicates the predetermined active period of the profile.

The attributes section of a profile can comprise a variable set ofattributes fields. As discussed, the attributes typically containpersonal information of the user. For asymmetric profiles, the firstattributes field can indicate whether the user of the device is a finderor a provider. How the remaining fields are populated and presented willdepend on the contents of this field. In some embodiments of theinvention it may be desirable to reference the attributes of the userwith an external database. For example, an estate agent, with a fixeddevice 200 set up to run the Property Finder Profile, may desire to linkthe attributes of this profile, which contains details of the propertieson their books, to a central database containing their list ofproperties. Alternatively a chain of book stores, with a fixed device200 set up to run the Book Finder Profile in each store, may desire tolink the list of books in stock in each store to a central stock takingdatabase. In such a situation, the link could be achieved by using awide area network or the Internet.

The requirements section of a profile may comprise a variable set ofsearch criteria fields. As discussed, unlike the attributes of the user,the requirements are sent to other devices during the matching process.

The handle will comprise the information sent to the user of thecompatible device when a two-way match is established. As discussed, theuse of a handle is optional.

The software used to populate the profiles, whether on a PC or on anintegrated device, recognises each field type, and accordingly generatesthe appropriate forms and presents the data in an appropriate way to theuser. The device similarly recognises the field type, and uses thisinformation to apply the correct algorithm when matching, in order toobtain a match or no match result for each field. The use of pre-definedfield types allows the device to parse any legally constructed profile,built from any combination of fields. Hence, as discussed, a 3^(rd)party could create and distribute a profile to suit any particular need.

In order to prevent malicious 3^(rd) parties from creating unsuitableprofiles for use with the children's embodiment of the invention, it isnot possible for a malicious party to download and activate a profile onanother user's device 10. A profile of any sort will only be useful ifit can be distributed and activated on user's devices.

Certain fields in a profile may be allowed to be kept unpopulated, i.e.blank. For example, a user may not wish to enter their age or salaryinto the attributes field of a Relationship Finder Profile. When a userenters their requirements for such an individual field that can be keptblank, they are given the option of specifying whether or not this fieldbe considered mandatory or not. This will set the mandatory flag for thefield to “true” or “false”. Selecting that an individual requirementsfield be mandatory will result in blank fields in other user'sattributes never returning a match. Conversely, selecting that arequirements field is not mandatory will always result in a match beingindicated with corresponding blank attribute fields.

The function of a field can depend on the context in which it appears.For example, a field may have a different function if it is located inthe attributes or requirements section of the profile. Several examplefield types will now be discussed with reference to Tables 2 to 11. Inthese tables, the selected values are those that are filled in by theuser when a profile is populated. TABLE 2 Finder-Provider Definition:Context Characteristic Attributes Requirements Field TypeFinder-Provider Not Applicable Intrinsic Value/s Finder, Provider NotApplicable Selected Values One of Finder or Provider Not Applicable

The finder-provider field type occurs as the first field in theAttributes section of every asymmetric profile. It is used to identifywhether the user populating the profile is designating themselves afinder or a provider. The value entered in this field is then used todetermine which other fields are presented to the user for population.

The Boolean field type records True/False information, as illustrated inTable 3, with an example in Table 4. TABLE 3 Boolean Definition: ContextCharacteristic Attributes Requirements Field Type Boolean BooleanIntrinsic Value/s True, False, Null True, False, Null Selected ValuesOne of True, False, NULL One of True, False, NULL

TABLE 4 Boolean Example: Context Characteristic Attributes RequirementsField Type Boolean Boolean Name Vegetarian Vegetarian Selected ValuesTrue NULL Meaning The owner is a The owner does not care if the otherVegetarian party is a Vegetarian

The integer numeric field type records and matches attributes andrequirements based on integer numeric information. In the illustrationof an integer numeric field type in Table 5, the user can enter aminimum/maximum pair of values. If the user desires to enter an absolutevalue, the apparatus populating the field would set both the minimum andmaximum values to be identical. Table 6 shows an illustrative example ofan integer numeric field type field, from within an asymmetric profile.TABLE 5 Integer Numeric Definition: Context Characteristic AttributesRequirements Field Type Numeric Numeric Value Type Integer, Null A Pairof Integers or NULL Selected Values A number of type N/A Integer, orNull Minimum Value N/A A number of type Integer, or Null Maximum ValueN/A A number of type Integer, or Null

TABLE 6 Integer Numeric Example from an asymmetric profile: ContextAttributes (from a REQUIREMENTS Characteristic Provider Profile) (from aFinder Profile) Field Type Numeric Numeric Name Wine's Vintage Wine'sVintage Selected Values 1947 N/A Minimum Value N/A NULL Maximum ValueN/A 1955 Meaning This owner is selling a This owner is looking for aparticular wine whose wine of a vintage no vintage is 1947 later than1955

The Selection field type allows the user to select from a pre-definedlist of alternative values. The creator of the profile structure canimplement a One/Many Flag characteristic to distinguish between liststhat require only one value to be selected, and those in which multiplevalues can be selected. The creator of the profile structure can alsoimplement the Include/Exclude Flag within the requirements section ofthe profile to allow the user to explicitly match (include) or fail(exclude) against particular attributes. TABLE 7 Selection Definition:CONTEXT Characteristic Attributes Requirements Field Type SelectionSelection Intrinsic Value/s Variable length list List of stringsobtained of Strings from the referenced ATTRIBUTES field One/Many FlagOne, Many One, Many Selected Values List of Strings List of Strings (asubset of (a subset of Intrinsic Intrinsic values) values)Include/Exclude Flag NULL Include, Exclude, NULL AND/OR Flag NULL AND,OR, NULL

Two examples of the selection field type will now be illustrated inTables 8 and 9. In Table 8 the creator of the profile has included twoseparate requirement instantiations for the Hobbies field, one forincluded items and another for excluded items. TABLE 8 Selection Example1 CONTEXT Characteristic Attributes Requirements Requirements 2 FieldType Selection Selection Selection Name Hobbies Hobbies Hobbies LegalValues (as “sport”, “theater”, * * provided by the “reading”, “longProfile's author) walks” One/Many Flag Many Many Many Selected Values“sport”, “reading” “theater” “long walks” “reading” Include/Exclude N/AInclude Exclude Flag AND/OR Flag N/A AND OR (Default) Meaning Ownerlikes sport Owner looking Owner wishes and reading for someone toexclude anyone who likes both who likes long theater and walks reading“*” = The list is referenced automatically from the Attributes fieldwithin the profile using the Field ID

Table 9 illustrates field from a “Last Minute Holidays” Profile, ascould be authored and distributed by a chain of travel agents. TABLE 9Selection Example 2 CONTEXT Characteristic Attributes RequirementsRequirements 2 Field Type Selection Selection Selection Name DestinationDestination Destination Legal Values “Greece”, * * “Canaries”, “Spain”,“Turkey”, . . . One/Many Flag One Many Many Selected “Greece” ALL“Spain”, Values “Turkey” Include/ N/A Include Exclude Exclude FlagAND/OR Flag N/A OR OR Meaning This owner/vendor This owner is . . .except is offering a last- looking for a Spain or minute holiday toHoliday to any Turkey Greece of the listed destinations . . .“*” = The list is referenced automatically from the Attributes fieldwithin the profile

In the example field type shown in Table 9, the AND/OR Flag will not bepresented to the user as an option when specifying their requirements.The apparatus used to populate a profile containing this field type willrecognise that when the attributes field allows only ‘One’ value, theuse of an AND operator would have no meaning. Furthermore, the provisionby the creator of the profile of an Exclude field (in addition to theInclude field) for the Destination is logically redundant. This isbecause the user populating the profile could have simply omitted bothSpain and Turkey from their Include selection. However, here the creatorof the profile has provided it for enhanced usability.

Fields of type Keyword allow users to specify a set of keywords, whichare in effect free text that can be matched against, and are illustratedin Tables 10 and 11. This could allow a profile to be extended beyondthe confines of its original design. For example, a Swap Shop Profilefor use with the children's embodiment of the invention could never bedesigned to encompass the vast and ever changing array of items that maybe bartered or swapped in the melee of the playground.

The provision of keyword field type allows users to extend theirexisting profiles to suit their needs. This reduces the need for newprofiles to be designed and distributed. Furthermore, it could allow,for example, communities of people to develop and use special codewords. TABLE 10 Keyword Definition: CONTEXT Characteristic AttributesRequirements Field Type Keyword Keyword Intrinsic Value/s Blank variablelength list Blank variable length list of of Strings Strings EnteredValues List of Strings List of Strings Exclude Flag N/A True, False,NULL AND Flag N/A True, False, NULL

An example of a keyword type field for use in a Swap Shop Profile isgiven in Table 11. TABLE 11 Keyword Example: CONTEXT CharacteristicAttributes Requirements Requirements 2 Field Type Keyword KeywordKeyword Name Item/s to Swap Item to Swap Item to Swap Contextual Blankvariable Blank variable Blank variable Values length list length listlength list of Strings of Strings of Strings Entered Values “Toy A” “ToyB” “Card C” “” Exclude Flag N/A False True AND Flag N/A False FalseMeaning The owner This owner is The owner is not has a Toy A looking forexcluding to swap anything to do anything with Toy A or Card C

The above field types are only exemplary, and it will be apparent thatmany additions or modifications to the above are possible. For example,other field types could include Date, Time, Exact Text and FloatingPoint Numeric.

The present invention has been described above purely by way of example,and those skilled in the art will recognise that many modifications canbe made within the scope of the invention. The invention also consistsin any individual features described or implicit herein or shown orimplicit in the drawings or any combination of any such features or anygeneralisation of any such features or combination, which extends toequivalents thereof.

Furthermore, although embodiments of the invention have been discussedthat rely on users physically locating each other after a match has beenestablished either unaided, or using the optional probe mode, otherembodiments of the invention could relay detailed positional informationto the user. This would require the use of a communications technologycapable of relaying positional information, such as 3G.

1. A communications device comprising: a memory adapted to store atleast one profile of a user of the device, wherein the said at least oneprofile contains predetermined attributes and requirements of the user,a transceiver adapted to transmit information relating to the saidrequirements to a compatible device and receive information relating torequirements of the said compatible device; a controller adapted toregister a match between the said device and the said compatible device,only when the said attributes match the said requirements of the saidcompatible device; and a user alert adapted to alert a user when thecontroller has established that a match has been made; wherein thetransceiver is further adapted to transmit a first match signal to thecompatible device when the controller has established that a match hasbeen made; wherein the said device does not need to receive informationrelating to attributes of the said compatible device, in order toregister a match with the said compatible device.
 2. A communicationsdevice according to claim 1, wherein the user alert is further adaptedto alert the user only when the controller has established that a matchhas been made and that a match signal has been received from thecompatible device, said match signal indicating that the compatibledevice has registered a corresponding match.
 3. A communications deviceaccording to claim 1 or 2, wherein the device further comprises adisplay.
 4. A communications device according to claim 3, wherein thedisplay is adapted to display an indication of the or each profilestored in the device.
 5. A communications device according to claim 4,wherein the device is further adapted to allow the user to designatewhich of the stored at least one profiles the user designates as active;the said memory is further adapted to store an indication of the activeprofile or profiles; and the communicator is further adapted to exchangeinformation with a compatible device based only on the active profile orprofiles.
 6. A communications device according to claim 5, wherein thedevice further comprises a keypad, said keypad being adapted to allow auser to activate a profile from those stored in the device.
 7. Acommunications device according to claim 5 or 6, wherein the display isfurther adapted to display an indication of the active profiles.
 8. Acommunications device according to any preceding claim, wherein thememory comprises a combination of volatile and non-volatile memory.
 9. Acommunications device according to any preceding claim, wherein the useralert is adapted to provide a visual indication to the user.
 10. Acommunications device according to claim 9 when dependent on claim 3,wherein the user alert is adapted to provide the visual indication usingthe display.
 11. A communications device according to claim 9, whereinthe user alert comprises at least one LED.
 12. A communications deviceaccording to any preceding claim, wherein the user alert is adapted toprovide an audible indication to the user.
 13. A communications deviceaccording to any preceding claim, wherein the user alert is adapted toprovide a vibrating indication to the user.
 14. A communications deviceaccording to any preceding claim, wherein the or each said profilecomprises a self-describing data file, each self-describing data filecomprising at least one field.
 15. A communications device according toany preceding claim, wherein the or each said profile comprises at leastone of a plurality of possible field types.
 16. A communications deviceaccording to any preceding claim, wherein the or each said profilecomprises one or more sets of fields of a keyword type, said one or moresets of fields allowing matching to be performed against user determinedfree text.
 17. A communications device according to any preceding claim,wherein the or each said profile comprises a field that can contain amandatory flag, the said mandatory flag indicating to the device whetherblank fields are required to always or never be matched against.
 18. Acommunications device according to any preceding claim, wherein thememory is adapted to store multiple instances of the same profile type;wherein the device is adapted to: match all the multiple instances ofthe same profile in a matching process that involves transmitting a twodimensional matrix of flags that indicate a match or no match, thecolumns of said matrix being indexed on the instances of the profilestored in the memory; receive a corresponding two dimensional matrixfrom the compatible device; transform the received matrix; and comparethe transformed received matrix with the sent matrix to identify any andall matches for this profile type.
 19. A communications device accordingto any preceding claim, wherein the or each said profile comprises aheader section, the header section comprising a unique profile ID of therespective profile.
 20. A communications device according to claim 19,wherein the header section is the only section of the or each saidprofile that cannot be modified by the user.
 21. A communications deviceaccording to any preceding claim, wherein the attributes andrequirements of the or each said profile are determined by the user. 22.A communications device according to any preceding claim, wherein thedevice is adapted to communicate with a suitably programmed computer.23. A communications device according to claim 22, wherein the device isadapted to communicate with the suitably programmed computer using acable connection between the device and the suitably programmedcomputer.
 24. A communications device according to claim 22, wherein thedevice is adapted to communicate with the suitably programmed computerusing the said transceiver.
 25. A communications device according to anyof claims 22 to 24, wherein the said device is adapted to store thepopulated at least one profile, upon receipt of information relating tothe said attributes and requirements from the said computer.
 26. Acommunications device according to one of claims 22 to 25, wherein thesaid device is adapted to store new profile types, upon receipt ofinformation relating to the said new profile types from the saidsuitably programmed computer.
 27. A communications device according toclaim 26, wherein the said information relating to the said new profiletypes has been downloaded to the said suitably programmed computer fromany of the Internet, an email attachment, or a MMS attachment.
 28. Acommunications device according to any preceding claim, wherein thedevice further comprises a timer and a timing register, and wherein thetiming register is adapted to store timing information for the or eachsaid profile.
 29. A communications device according to claim 28, whereinthe timing information comprises a predetermined active period for theor each said profile.
 30. A communications device according to claim 27or 28, wherein the timing information comprises a schedule relating tothe activation and deactivation of the or each said profile at userdefined times.
 31. A communications device according to any precedingclaim, wherein the device is further adapted to store a unique ID of thedevice.
 32. A communications device according to any preceding claim,wherein the memory comprises a recent encounters cache, the said recentencounters cache comprising a list of received unique IDs of compatibledevices that have communicated with the device.
 33. A communicationsdevice according to any preceding claim, wherein the device is furtheradapted to allow the user to blacklist compatible devices after theestablishment of a match, and wherein the memory comprises a blacklistcache, the said blacklist cache comprising a list of received unique IDsof compatible devices that the user has blacklisted.
 34. Acommunications device according to any preceding claim, wherein thedevice further comprises a probe alert, the said probe alert beingadapted to aid the user physically to locate the user of the compatibledevice once a match has been established.
 35. A communications deviceaccording to claim 34, wherein the said probe alert is adapted toprovide a visual location indication to the user.
 36. A communicationsdevice according to claim 35, wherein the said probe alert comprises atleast one LED.
 37. A communications device according to one of claims 34to 36, wherein said probe alert is adapted to provide the visuallocation indication to the user using the display.
 38. A communicationsdevice according to one of claims 34 to 37, wherein the said probe alertis adapted to provide an audible location indication.
 39. Acommunications device according to one of claims 34 to 38, wherein thesaid probe alert is adapted to provide a vibrating location indication.40. A communications device according to any preceding claim, whereinthe device is further adapted to store at least one handle, the or eachsaid handle generally comprising a string of characters, and wherein thedevice is adapted to enable the or each said handle to be sent to thecompatible device on the establishment of a match.
 41. A communicationsdevice according to claim 40, wherein the or each said handle comprisesinformation pertaining to the established match.
 42. A communicationsdevice according to any preceding claim, wherein the memory is furtheradapted to store a match log, the said match log comprising informationregarding previously established matches.
 43. A communications deviceaccording to claim 42 when dependent on claim 40 or 41, wherein thematch log comprises a unique ID of each previously matched compatibledevice along with match information comprised in any received handles.44. A communications device according to claim 42 or 43, wherein thematch log further comprises information regarding details ofcommunications between the device and compatible devices that did notresult in a match.
 45. A communications device according to any ofclaims 42 to 44 when dependent on claim 22, wherein the device isfurther adapted to upload the contents of the match log to the suitablyprogrammed computer.
 46. A communications device according to claim 19or any claim dependent upon claim 19, wherein the memory is adapted tostore only profiles that comprise a predetermined flag in the headersection.
 47. A communications device according to claim 46, wherein thepredetermined flag is formed from a number of bits of the Profile ID,and wherein the device is adapted to only match with compatible devicesthat have at least one stored profile with an identical correspondingbit set of the predetermined flag.
 48. A communications device accordingto any preceding claim, wherein the transceiver is adapted to exchangeinformation with the compatible device using short range wirelesscommunications.
 49. A communications device according to claim 48,wherein the short range wireless communications employs radio ormicrowave transmission.
 50. A communications device according to claim48, wherein the wireless communication employs Bluetooth or Wi-Fitransmission.
 51. A communications device according to claim 48, whereinthe wireless communication employs any location aware telecommunicationsnetwork.
 52. A communications device according to claim 51, wherein thelocation aware telecommunications network employs 3G transmission.
 53. Acommunications device according to any preceding claim, wherein thetransceiver is adapted to exchange information with the compatibledevice using long range wireless communications.
 54. A communicationsdevice according to any preceding claim, wherein the device is aportable device.
 55. A communications device according to claim 54,wherein the portable device is any one of, or a combination of: a mobiletelephone, a PDA, a pager, a palmtop computer, a notebook computer or alaptop computer.
 56. A communications device according to claim 55,wherein the device is further adapted to perform any one of, or acombination of: populating the or each said profile, creating newprofiles, connecting to the Internet or accessing email or MMSattachments and downloading new profiles.
 57. A communications deviceaccording to any of claims 1 to 53, wherein the device is not portable.58. A communications device according to claim 57, wherein the device isany of: a personal computer, workstation, server, or terminal.
 59. Acommunications device according to claim 57 or 58, wherein the device isadapted to perform any one of, or a combination of: populating the oreach said profile, creating new profiles, connecting to the Internet oraccessing email of MMS attachments and downloading new profiles.
 60. Acommunications device according to claim 14, or any claim dependent uponclaim 14, wherein the memory is adapted to store at least one profilethat is a symmetric profile, the said symmetric profile comprising a setof attributes and requirements fields which is adapted to be symmetricwith respect to that of a compatible device.
 61. A communications deviceaccording to claim 14, or any claim dependent upon claim 14, wherein thememory is adapted to store at least one profile that is an asymmetricprofile, the said asymmetric profile comprising a set of attributes andrequirements fields that is adapted to be asymmetric with respect tothat of a compatible device.
 62. A communications device according toclaim 61 when dependent on claim 19, wherein the device is adapted tostore an indication of whether the user is a provider or a finder in theprofile.
 63. A communications device according to claim 61 or 62,wherein the said asymmetric profile comprises multiple instances of theattributes of the user.
 64. A communications device according to any ofclaims 61 to 63, wherein the device is adapted to populate theattributes of the said asymmetric profile by referencing an externaldatabase, the said external database being stored on any of a LAN, aWAN, personal computer, workstation, server, terminal or the Internet.65. A communications device according to claim 64, wherein the device isadapted to store the results of the reference to the external databaseafter a match has been established, if the user of the compatible devicebecomes out of range before the user of the device is be alerted to thematch; and alert the user to the match if the user of the compatibledevice becomes in range again within a predetermined time period,without referring to the external database again.
 66. A communicationsdevice according to claim 51 or any claim dependent on claim 51, whereinthe device is adapted to upload the or each said profile to a centraldatabase, said central database being adapted to store locationinformation relating to the users; and match users based on theattributes and requirements of the or each said profile and the locationinformation relating to the users.
 67. A communications devicesubstantially as hereinbefore described with reference to theaccompanying drawings.
 68. A communications method comprising the stepsof: storing at least one profile of a user in a memory of acommunications device, wherein the or each said profile containspredetermined attributes and requirements of the user; using atransceiver of the device to transmit information relating to the saidrequirements to a compatible device and receive information relating torequirements of the said compatible device; using a controller toregister a match between the said device and the said compatible device,only when the said attributes match the said requirements of the saidcompatible device; using a user alert to alert a user when thecontroller has established that a match has been made; and using thetransceiver to transmit a first match signal to the said compatibledevice when the controller has established that a match has been made;wherein the said device does not need to receive information relating toattributes of the said compatible device, in order to register a matchwith the said compatible device.
 69. A communications method accordingto claim 68, wherein the user is alerted only when a match has beenregistered and a match signal has been received from the compatibledevice, the said match signal indicating that the compatible device hasregistered a corresponding match.
 70. A communications method accordingto claim 68 or 69, further comprising the step of using a display todisplay an indication of the profiles stored in the device.
 71. Acommunications method according to claim 70, further comprising thesteps of allowing the user to designate which of the stored at least oneprofiles are designated as active; storing an indication of the activeprofile or profiles in the memory; and exchanging information with acompatible device based only on the active profile or profiles.
 72. Acommunications method according to claim 71, further comprising the stepof using a keypad to activate a profile from those stored in the device.73. A communications method according to claim 72, further comprisingthe step of using the display to display an indication of the activeprofile or profiles.
 74. A communications method according to any ofclaims 68 to 73, wherein the memory comprises a combination of volatileand non-volatile memory.
 75. A communications method according to any ofclaims 68 to 74, further comprising the step of using the user alert toprovide a visual indication to the user.
 76. A communications methodaccording to claim 75 when dependent on claim 70, further comprising thestep of providing the visual indication using the display.
 77. Acommunications method according to claim 75, further comprising the stepof providing the visual indication using at least one LED.
 78. Acommunications method according to any of claims 68 to 77, furthercomprising the step of using the user alert to provide an audibleindication to the user.
 79. A communications method according to any ofclaims 68 to 78, further comprising the step of using the user alert toprovide a vibrating indication to the user.
 80. A communications methodaccording to any of claims 68 to 79, wherein the or each said profilecomprises a self-describing data file, each self-describing data filecomprising at least one field.
 81. A communications method according toany of claims 68 to 80, wherein the or each said profile comprises atleast one of a plurality of possible field types.
 82. A communicationsmethod according to any of claims 68 to 81, wherein the or each saidprofile comprises one or more sets of fields of a keyword type, said oneor more sets of fields allowing matching to be performed against userdetermined free text.
 83. A communications method according to any ofclaims 68 to 82, wherein the or each said profile comprises a field thatcan contain a mandatory flag, the said mandatory flag indicating to thedevice whether blank fields are required to always or never be matchedagainst.
 84. A communications method according to any of claims 68 to83, further comprising the steps use storing multiple instances of thesame profile type in the memory; matching all the multiple instances ofthe same profile in a matching process that involves transmitting a twodimensional matrix of flags that indicate a match or no match, thecolumns of said matrix being indexed on the instances of the profilestored in the memory; receiving a corresponding two dimensional matrixfrom the compatible device; transforming the received matrix; andcomparing the transformed received matrix with the sent matrix toidentify any and all matches for this profile type.
 85. A communicationsmethod according to any of claims 68 to 84, wherein the or each saidprofile comprises a header section, the header section comprising aunique profile ID of the respective profile.
 86. A communications methodaccording to claim 85, wherein the header section is the only section ofthe or each said profile that cannot be modified by the user.
 87. Acommunications method according to any of claims 68 to 86 wherein theuser determines the attributes and requirements of the at least oneprofile.
 88. A communications method according to any of claims 65 to87, wherein the device communicates with a suitably programmed computer.89. A communications method according to claim 88, wherein the devicecommunicates with the suitably programmed computer using a cableconnection between the device and the suitably programmed computer. 90.A communications method according to claim 88, wherein the devicecommunicates with the suitably programmed computer using the saidtransceiver.
 91. A communications method according to any of claims 88to 90, wherein the device stores the populated at least one profile,upon receipt of information relating to the said attributes andrequirements from the said computer.
 92. A communications methodaccording to one of claims 88 to 91, wherein the device stores newprofile types, upon receipt of information relating to said new profiletypes from said suitably programmed computer.
 93. A communicationsmethod according to claim 92, wherein the said information relating tothe said new profile types is downloaded to said suitably programmedcomputer from any of the Internet, an email attachment or MMSattachment.
 94. A communications method according to any of claims 68 to93, further comprising the step of storing timing information for the oreach said profile in a timing register.
 95. A communications methodaccording to claim 94, wherein the timing information comprises apredetermined active period for the or each said profile.
 96. Acommunications method according to claim 94 or 95, wherein the timinginformation comprises a schedule relating to the activation anddeactivation of the or each said profile at user defined times.
 97. Acommunications method according to any of claims 68 to 96, wherein thedevice stores a unique ID of the device.
 98. A communications methodaccording to any of claims 68 to 97, wherein the memory comprises arecent encounters cache, the said recent encounters cache comprising alist of received unique IDs of compatible devices that have communicatedwith the device.
 99. A communications method according to any of claims68 to 98 wherein the user can optionally blacklist compatible devicesafter the establishment of a match, and wherein the memory comprises ablacklist cache, the said blacklist cache comprising a list of receivedunique IDs of compatible devices that the user has blacklisted.
 100. Acommunications method according to any of claims 68 to 99, furthercomprising the step of using a probe alert to aid the user to physicallylocate the user of the compatible device once a match has beenestablished.
 101. A communications method according to claim 100,wherein the said probe alert provides a visual location indication tothe user.
 102. A communications method according to claim 101, whereinthe said probe alert comprises at least one LED.
 103. A communicationsmethod according to any of claims 100 to 102, wherein the said probealert uses the display to provide the visual location to the user. 104.A communications method according to any of claims 100 to 103, whereinthe said probe alert provides an audible location indication to theuser.
 105. A communications method according to any of claims 100 to104, wherein the said probe alert provides a vibrating locationindication.
 106. A communications method according to any of claims 68to 105, wherein at least one handle of the user is stored in the device,the or each said handle generally comprising a string of characters, andwherein the device sends the or each said handle to the compatibledevice on the establishment of a match.
 107. A communications methodaccording to claim 106, wherein the or each said handle comprisesinformation pertaining to the established match.
 108. A communicationsmethod according to any of claims 68 to 107, wherein a match log isstored in the memory, the said match log comprising informationregarding previously established matches.
 109. A communications methodaccording claim 108 when dependent on claim 106 or 107, wherein thematch log comprises a unique ID of each previously matched compatibledevice along with any received handles.
 110. A communications methodaccording to claim 108 or 109, wherein the match log further comprisesinformation regarding details of communications between the device andcompatible devices that did not result in a match.
 111. A communicationsmethod according to any of claims 108 to 110 when dependent on claim 88,wherein the device uploads the contents of the match log to the suitablyprogrammed computer.
 112. A communications method according to claim 85or any claim dependent upon claim 85, wherein only profiles thatcomprise a predetermined flag in the header section are stored in thememory.
 113. A communications method according to claim 11 2, whereinthe predetermined flag is formed from a number of bits of the ProfileID, and wherein the device only attempts to match with compatibledevices that have at least one stored profile with an identicalcorresponding bit set of the predetermined flag.
 114. A communicationsmethod according to any of claims 68 to 113, wherein the transceiverexchanges information with the compatible device using short rangewireless communications.
 115. A communications method according to claim114, wherein the short range wireless communications employs radio ormicrowave transmission.
 116. A communications method according to claim114, wherein the wireless communications employs Bluetooth or Wi-Fitransmission.
 117. A communications method according to claim 114,wherein the wireless communication employs any location awaretelecommunications network.
 118. A communications method according toclaim 117, wherein the location aware telecommunications network employs3G transmission.
 119. A communications method according to any of claims68 to 118, wherein the transceiver exchanges information with thecompatible device using long range wireless communications.
 120. Acommunications method according to any of claims 68 to 119, wherein thedevice is a portable device.
 121. A communications method according toclaim 120, wherein the portable device is any one of or a combinationof: a mobile telephone, a PDA, a pager, a palmtop computer, a notebookcomputer or a laptop computer.
 122. A communications method according toclaim 121, further comprising the steps of using the portable integrateddevice to perform any one of, or a combination of: populating the oreach said profile, creating new profiles, connecting to the Internet oraccessing email or MMS attachments and downloading new profiles.
 123. Acommunications method according to any of claims 68 to 119, wherein thedevice is not portable.
 124. A communications method according to claim123, wherein the device is any of: a personal computer, workstation,server, or terminal.
 125. A communications method according to claim 123or 124, further comprising the steps of using the device to perform anyone of, or a combination of: populating the or each said profile,creating new profiles, connecting to the Internet or accessing email orMMS attachments and downloading new profiles.
 126. A communicationsmethod according to claim 80, or any claim dependent upon claim 80,wherein at least one profile that is a symmetric profile is stored inthe memory, the said symmetric profile comprising a set of attributesand requirements fields which is adapted to be symmetric with respect tothat of a compatible device.
 127. A communications method according toclaim 80, or any claim dependent upon claim 80, wherein the memory isadapted to store at least one profile that is an asymmetric profile, thesaid asymmetric profile comprising a set of attributes and requirementsfields that is adapted to be asymmetric with respect to that of acompatible device.
 128. A communications method according to claim 127when dependent on claim 85, wherein the device is adapted to store anindication of whether the user is a provider or a finder in the profile.129. A communications method according to claim 127 or 128, wherein thesaid asymmetric profile comprises multiple instances of the attributesof the user.
 130. A communications method according to any of claims 127to 129, wherein the device populates the attributes of the saidasymmetric profile by referencing an external database, the saidexternal database being stored on any of a LAN, a WAN, personalcomputer, workstation, server, terminal or the Internet.
 131. Acommunications method according to claim 130, further comprising thesteps of storing the results of the reference to the external databaseafter a match has been established, if the user of the compatible devicebecomes out of range before the user of the device is be alerted to thematch; and alerting the user to the match if the user of the compatibledevice becomes in range again within a predetermined time period,without referring to the external database again.
 132. A communicationsmethod according to claim 117 or any claim dependent on claim 117,further comprising the steps of uploading the or each said profile to acentral database, said central database being adapted to store locationinformation relating to the users; and matching users based on theattributes and requirements of the or each said profile and the locationinformation relating to the users.
 133. A communications methodsubstantially as hereinbefore described with reference to theaccompanying drawings.
 134. A communications system comprising at leasttwo communication devices as claimed in claim 60, wherein the controllerof each device is respectively adapted to register a match between thedevice and the other device based on the symmetric profile, wherein thesystem is adapted to treat the attributes and requirements of eachrespective user equally.
 135. A communications system comprising atleast two communication devices as claimed in claim 61, wherein thecontroller of each device is respectively adapted to register a matchbetween the device and the other device based on the asymmetric profile,wherein the system is adapted to treat the attributes and requirementsof each respective user differently.